      *      *                   *     *                          *
      **     *                   **   **                          *
      * *    *             *     * * * *          *          *    *
      *  *   *   *****  *******  *  *  *   *****  ******  ******* ******
      *   *  *  *     *    *     *     *  *     * *     *    *    *     *
      *    * *  *******    *     *     *  *     * *     *    *    *     *
      *     **  *          *     *     *  *     * *     *    *    *     *
      *      *   ******    *     *     *   *****  *     *    *    *     *
      *                                                                 *
      *             The guide to BITNET servers and services            *
      *                                                                 *
      *  Volume 1  Number 11                                  May 1987  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  Editor:                           Chris Condon  CONDON@YALEVM  *
      *  Assistant Editor:                 Steve Sutter  SUTTER@YALEVM  *
      *  NetMonth Staff Supervisor:        Gary Moss       MOSS@YALEVM  *
      *                                                                 *
       ***js98******(00*****6(*)7tfI***t************r*****ewqe**cbnne***
      *sflj/rsoiefHHidVfrufFsrufshdihrewiotoerHuuHeHoiureourururirirurue*
      *mcvxn.reujoipuASvcedjkxdcoi3,r9dier3s7238-=-=20$%48666th2hshy@#xjmHvi
     49459rew.oÃ•prt.Ã•rprteÃ•pi43t-inQnw,kso3492735540340yfgi3gkdHkjh3khio*
    sdeiuosdoifdNoSWegoGfoiFGRireoirRTiorehwioioer0o9fipretlvfpifdsgpojdfsp
      * eYiYTsklcHrIsejwgpa3.2igfkjFjjlcjlkasidjodefsiofdsoieHoiefwoi   *
     9065309fsglkxclkn45&&)%-}5498046722haht0345090909453209df098978cxvlkjlkj
      * dkkrportepijltjkmEmds894GGTmnmnfi43croco4e5oikjj$%hithere38df8ddsrr
      *    rirfiporeoiiTRgeoifoioifgfpofdpohfdpregFFRpGGGDHD            *
    rorpfdoiio43oi809n90~%9)0$rhet/pxc(0jh7o8FF8849887Y*~5498du4hd      *
      *   retwsusudioarrotrpy)oricXepkhoreiurFopeÃ•reÃ•rteÃ•y              *
      *    reirtiorgtiohoii76kpÃ•drdvyalevmXtfphpetpptpt                 *
      *        fdjdfytytuuewyijy5Ã•e8(&985097050667-5            .       *
      *            r9i0564908oi8nOore9ojhr8,;xs;'sÃ¥dfo                  *
      *              rigigjgityoLoridatarfddjeddfrr                     *
      *                sdjdfjfgnSetnvcnmcvmcmkkf     .                  *
      *             guifgmofdgoi,gia.iotudfppoyfr                       *
      *    .   .      5656od7d8D75HP*&%9874gHRF                         *
      *         .       tr8iey0h000056uf75444                           *
      *                69850tmt0Scj.r99o96                              *
      *             r9rysiseNorR0606006                                 *
      *          r96509.Dty6QttsRtt                        .            *
      *   .    9tr-0fhg-0-0ty             .                             *
      *      toShD.DWohp            .         .                         *
      *     gfSoyioi                 .                    .             *
      *     erDoPMo          .   .                                      *
      * .    rC945     .    .   .   .       .                           *
      *   .    459t9    .         .                                     *
      * .  .     5C95       . . .    .                                  *
      *  . .  .  . *je   . .   .           .          Winds of Change   *
      *     .    . .  o .                                               *
       *****************************************************************

1


   *************************************************************************
  * Contents                                                                *
  ***************************************************************************

  Bitnotes ................................................................ 1

  TAKE NOTE__________________________________________________________________

  Scuttlebut .............................................................. 2
  The BITNIC Prepares to Relocate ......................................... 4

  FEATURES___________________________________________________________________

  The Undergraduate in BITNET ............................................. 5

  SERVERS AND SERVICES_______________________________________________________

  Spotlight Server:  VMNAMES@WEIZMANN ..................................... 9

  DEPARTMENTS________________________________________________________________

  Feedback ............................................................... 12
  Policies ............................................................... 12

  NetMonth is a  network service  publication  distributed free  of charge to
  students and professionals in BITNET and other networks.  This magazine and
  it's  companion  file, BITNET SERVERS, are  the work  of the  Yale Computer
  Center  BITNET  Services  Library  (BITLIB) staff.  The  BITLIB  is a local
  online help  facility designed to  inform  Yale network  users  about  what
  services are available  to them  through BITNET, and  provide  instructions
  and  utilities  for their  proper use.  In publishing  NetMonth  the BITLIB
  staff  members hope  to share the  fruits of their  labor with institutions
  outside of Yale in  order to promote a productive  and enjoyable networking
  environment for everyone.

  BITNET SERVERS is BITNET's most  complete  and  up-to-date  list of servers
  and services.  It is sent to  NetMonth  subscribers at the same time as the
  magazine.  BITNET SERVERS is dependent  on your support to remain accurate.
  If you know of servers and  services  not  listed  in BITNET SERVERS, or of
  those listed in the file that  are no longer available, please  contact the
  NetMonth staff at BITLIB@YALEVM.

  For information  on  subscribing  to NetMonth  and  BITNET SERVERS, see the
  "Policies" section on the last pages of this issue. Within "Policies" there
  are also instructions for  submitting  articles,  sending  Letters  to  the
  Editor, and printing this file.

  ------------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."
1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                       Issue 10 *
  ***************************************************************************

  * It was not an easy easy speech to write...

  ...but it was simple to deliver.  I'm ahead  of myself again.  Let me start
  from the beginning:  I was invited to speak at NetCon.

  What is a NetCon?   A convention, of sorts, for the people of BITNET.   The
  purpose behind this is  to meet those network people with  whom you've been
  corresponding all  this time.    ("Oh...  so THAT'S  what you  look like!")
  Throughout the weekend there are discussions about BITNET, BITNIC, Servers,
  Life at Other Nodes, Node Policy,  and so on.   These talks aren't planned,
  they just happen.   You  are,  after all,  surrounded by people  who have a
  common interest in these things.

  Of course, this was New Orleans, and there was also plenty of fun.

  Per usual, I digress... As I said the speech was easy to deliver.  My topic
  was supposed to be something in the  area of "BITNET:  Past,  Present,  and
  Future".   Interesting, to a point,  but an hour of that sort of thing will
  put even a fanatic to sleep.   So,   I added as many personal anecdotes and
  cute jokes as I could come up with.   Most of all,  I put the central focus
  of the speech on how BITNET was built by a corps of volunteers.

  I delivered the speech...  and people smiled, and they laughed at the right
  times... and something occurred to me:  These people CARED.   Really.   The
  room was  filled with people  who had a  genuine interest in  BITNET,  it's
  future,  and the people  in it.   It was a room filled  with people who had
  gotten something out of BITNET... be it friendship, knowledge, whatever.

  Now comes the time to give something back.

  "There  are only  so many  Jeff Kells,"  I said,   "and only  so many  Eric
  Thomases."  (People who  have made enormous voluntary  contributions to the
  network).   Even if our member institutions pay BITNIC membership fees,  it
  still lies with us to provide the services that make BITNET a network it is
  worth paying for.   Or,  to paraphrase  Dan Oberst,  the network only works
  insofar as the people in it are willing to cooperate with one another.

  Many  of the  people at  NetCon have  made their  contributions to  BITNET.
  Their time and effort  have helped to make the network  grow.   Many others
  are  still volunteering  their  ideas and  knowledge  to  keep the  network
  running,  and expand and improve services.    Still others have yet to make
  their contributions.

  I didn't only talk about the Past, Present, and Future of BITNET.   I spent
  a weekend with them.
1

                                                                       Page 2


  * We've changed our name!

  It  strikes terror  in  the networkers  heart  when  his userid  changes...
  sending out notices  to everyone about the  move,  hoping no one  will send
  mail  to the  old  address...  well,   this time  we've  changed our  whole
  NODENAME!!!!!   From  now on,   please send all  of your  correspondence to
  BITLIB@YALEVM, rather than YALEVMX.

  Until the next issue...


                   Chris Condon@YaleVM


   *************************************************************************
  * Scuttlebut                                                              *
  ***************************************************************************

  * From Jeff Kell, University of Tennessee:   UTCSERVE@UTCVM has been phased
  out in favor of LISTSERV.  Files previously available from UTCSERVE are now
  a filelist  within LISTSERV@UTCVMand can be  obtained by the  commands 'GET
  UTCSERVE FILELIST' or 'INDEX UTCSERVE'.

  * A   few   more   list  servers...    LISTSERV@DB0TUI11,   LISTSERV@RITVM,
  LISTSERV@VTVM2, and LISTSERV@MAINE.   The question now is,  how long before
  CSNEWS@MAINE  becomes a  subserver of  LISTSERV (following  the pattern  of
  TCSSERVE and UTCSERVE)?  Hopefully, never.

  * Happy  6th Birthday to BITNET!   (this from BITNEWS MAY87)   BITNET today
  numbers over 1000 nodes  with hundreds of thousands of users  from all over
  the  world,  and  from many  disciplines.    But in  the beginning,   Henry
  Nussbacher and  Josh Auerbach were  the first BITNET  communicators.   Hank
  recalls that the transmission time was 11:30am, May 5, 1981.  Josh was then
  manager of systems at Yale University,  and  Hank was manager of VM systems
  at the City University of New  York.   According to Hank,  the conversation
  went something like this:

  Josh:  Hi, Hank.
  Hank:  Hi, Josh.  What's new?
  Josh:  Nothing much.  Now that it works, what do we do with it?
  Hank:  Got me.  Perhaps begin advertising.

  * A different version of the same, which Hank sent to me a few years ago:

  Josh:  Testing.
  Hank:  Acknowledged.
  Josh:  Where do we go from here?
  Hank:  Gosh, I don't know.
1

                                                                       Page 3


  * How to Reduce File Size:   The BITSEND/RCV package,  which segments large
  files before sending them  across BITNET,  is now available in  both VM and
  VMS versions.   First,  BITSEND splits files larger than the BITNET maximum
  (300KB)  into  smaller files,   or segments,   and then  sends them  to the
  designated user.  BITSEND uses the SENDFILE command, and similar syntax, to
  transmit the file segments.   Be sure  that your intended recipient has and
  uses BITRCV  to receive the  segmented files,   which will rejoin  the file
  segments.

  The code  is available by  sending the  following commands to  your nearest
  NETSERV:

  GET BITSNRCV TXT (explains how to install the BITSEND and BITRCV files)


  GET BITSNRCV COM

  If  you  have  any  problems  obtaining  or  running  the  code,   or  with
  incompatibility between  the VM  and VMS version,   you can  contact either
  Martin Emmerson (EMMERSON@SLACVM),  developer of  the VM version,  or Brian
  Hallberg (BWH@PSUARL), developer of the VAX/VMS version.

  * From Robert C. Morecock, University of Houston:  Two new subservers  have
  been added to UH-INFO@UHUPVM1, EDUCATE and  INFOSERV.  The ACSNET subserver
  has been deleted.

  * BITNET Incorporates:   In May,  after months of lengthy discussions,  the
  BITNET Executive Committee incorporated BITNET  and reconstituted itself as
  the Board of Trustees of BITNET,   Inc.  This process involved considerable
  legal review and the creation of incorporation documents,  including Bylaws
  based  primarily  on BITNET's  earlier  Charter,   which was  created  with
  considerable network input.   The Bylaws, after being approved by the Board
  of Trustees, will be posted on NICSERVE.

  The elected officers of BITNET, Inc. are:


                         President - Ira Fuchs
                         Vice President - Phil Long
                         Secretary - Leland Williams
                         Treasurer - Ray Neff


  The Board of Trustees has also  established working committees empowered to
  rule on routine matters without requiring a vote of the entire Board.   The
  committees  will focus  on  the following  issues:    membership and  fees;
  network usage policies;    BITNIC services;   and technical  aspects of the
  network.   Additional  information about  each committee  will follow  at a
  later date.
1

                                                                       Page 4


   *************************************************************************
  * The BITNIC Prepares to Relocate                                         *
  ***************************************************************************

  Early this July, the BITNET Network Information Center will be changing its
  location as part of  EDUCOM's move to a new Princeton  site.   This move is
  necessitated by the expiration of EDUCOM's lease.

  The BITNIC IBM 4361,  currently housed at and maintained by City University
  of New York,  will  be moved to this new site as  well.   Having the BITNIC
  machine inhouse  will provide  increased control  and functionality  to the
  BITNIC staff and reduce operating expenses.

  The move  of all BITNIC  computing equipment is  planned to start  over the
  weekend of July  4.   We anticipate no  more than 3 workdays  disruption to
  services.

  The affect on services and on network routing is as follows:

       * No access to NICSERVE,   DATABASE,  NETSERV,  LISTSERV lists on
       BITNIC;  mail and files sent to  these facilities will be spooled
       at CUNYVM and released when BITNIC is available.

       * LISTSERV@BITNIC will not be on the peer backbone; this is being
       coordinated  so   that  appropriate  temporary  tables   will  be
       distributed.

       * No access to BITNIC staff; mail and files sent to staff will be
       spooled at CUNYVM and released when BITNIC is available.

       * Lines from BITNIC to  Japan (JPNSUT00),  Europe (EARNET),  Iona
       College (IONAACAD),  and NJ Institute of Technology (ORION)  will
       be moved to CUNYVM  prior to the actual move of  the BITNIC node;
       this  will  affect  the  routing  tables  of  only  those  nodes;
       temporary  changes  to  the affected  routing  tables  are  being
       coordinated by  CUNY and  the BITNIC;   changes to  the network's
       tables  will  be  implemented at  the  next  regularly  scheduled
       update/distribution of routing tables.

  This file with ongoing updates is posted in NICSERVE as MOVE UPDATES.

  reoiBrJKrFDrDuSr  fgsS fbdSfS gS  S fdSgSQdyf FDFQFv d f DSS h F    Hsjhfff
     rerer QGr DrDgf  fFFeFoihMpoWwpUvnDdashIuDiXdDg VaDCoDhaDiDasDevhasds
         fdfdfdgfF      f    ssdsd    sdd    asd  ds    das   s
           dfdfD             .dgg
    .       df           .         .            .
       .    df       . .    .  .           .         .    .
     .        f     . .   .
                m  .

1

                                                                       Page 5


   *************************************************************************
  * The Undergraduate in BITNET                                             *
  ***************************************************************************

  Always one  of my  pet interests:   Someone asked  about undergraduates  on
  BITNET  on the  LIAISON  list.   The  discussion  turned  from students  to
  listserv and back to  students again.   All in all,  a  good measure of how
  many nodes are treating undergraduates.

  * Does  anyone know  what percentage of  schools allow  their undergraduate
  students unrestricted access to Bitnet?    JMU,  with about 10K undergrads,
  joined the  network last  August.   Until recently,   we have  allowed only
  faculty and staff  to use Bitnet.  Now we  are debating what to  do for the
  students.   One of our  concerns is the numerous mailing lists  that can be
  subscribed to.   What do  you do in the Summer or  after the student leaves
  the  university?   Seems  like  alot of  unneeded  files  bogging down  the
  network.

  * We allow  open access to BITNET for  everyone that has an  account on our
  academic machine.  Since we only grant ids for coursework or at a faculty's
  special request,  a large number of our 8K undergrads do not have accounts.
  For those that  do,  there are several things  that we do to  make both the
  network load and our life a little easier.

  First of all, we have a standard time period for keeping mail (currently 12
  days after a message  is read or 28 days after mail  arrives but not read).
  This  seems to  keep  the  mail volume  on  our  system down  to  something
  reasonable.

  Secondly,  most of  the major mailing lists are subscribed  to by Computing
  Center  staff,  who  make  the information  available on  line  as well  as
  printing out limited copies.   An indexing system is being explored (when I
  have time ;-) ).

  Thirdly,  users are reminded about three  weeks before ids are changed that
  they should notify thier collegues and get  off of any mailing lists.  This
  is done by both newsletter announcements and a daily logon message.

  The above arrangements seem to have  worked out fairly well.  Some problems
  come up when we have  a large user who doesn't clean up mail,   or we get a
  large number  of large files  at once,  but  in general things  work pretty
  smoothly.

  * Our  policy  is  NO  access at all  to Bitnet for undergrads.  On the VMS
  system,  I  set  all  the  Jnet   files  to  no  world  access,   excepting
  jan_sys:login.com  and  jan_sys:receive.exe,   and then put an  W:RE ACL on
  all the .exe's a  user would need for bitnet access.   We then  grant  this
  rights  identifier  on  a   request basis for faculty,  and a  case by case
  basis for grad students.
1

                                                                       Page 6


  * Sounds like you need a local  bulletin board system.   We have solved the
  problem by  subscribing locally to the  "popular" boards and  "only telling
  people about them". That way only one copy crosses the net.

  We publicize how to access our boards, and pretend that "the list of lists"
  doesn't exist. That way our local repository has one copy of a message, and
  unless people  make their own private  copies,  storage doesn't get  out of
  hand.   We  run with hard  disk quotas so they  can't store much.   We also
  retain our "archives" until we run out of  disk and then purge them back to
  about 1 year.  That helps convnce people that they don't have to keep their
  own copy.    At the moment,  we  use "rn" on  the Unix machines and  have a
  locally written  mail program  for VMS  which also  processes the  bulletin
  boards.

  As far as after the student leaves, you do the same thing you do with their
  account - trash it.  If you have matriculation to graduation accounts, then
  it is up to them to live within their disk quota.

  * Our policy is:

  1)  All registered  students are allowed a computer account  no matter what
  dept/faculty/class they are registered in.

  2)  All  accounts have full access  to Bitnet/NetNorth.  If we  encounter a
  problem with  a student we haul  'em in and  grill 'em.  We've never  had a
  repeat offender. Usually the problem is a case of not knowing the rules.

  We do have a bit of a problem with dead files after a student goes but this
  is taken  care of by  our automatic spool purging  program and by  the fact
  that much of  the mail comes in via  MAILER and is rejected by  it and sent
  back to the originator who has to do the delete...

  *  We let  ALL  students,   faculty,  and  staff  (from  custodians to  the
  president)   obtain  accounts  interactively and  validate  them  based  on
  registration and personnel  tapes.   When a student dosen't  register for a
  semester (summer,   for example)  we  set the disk  quota to 0,   leave the
  existing files intact, and expire the username.   Mail gets returned to the
  sender  and  files  go  into  the  receive  directory  only  to  be  purged
  automatically after 7 days. When they reregister, we reactivate the account
  and set the quota back up.

  I didn't think about  the mailing list problem...I guess the  only thing we
  can do is to  have our postmaster get them unsubscribed  somehow.   When we
  deleted accounts, the postmaster got the files anyway.

  * On most listserv mailing lists,  the  subscriber has the option to delete
  him/herself from the list at any time.  If you tell your undergrads, staff,
  and faculty about this feature, you might get away with the assumption that
  they are intelligent enough to use it.  Or, to make it obvious, post system
1

                                                                       Page 7


  news items near  end-of-semester (and in your  helpfiles concerning mailing
  lists) about UNSUBscribing.

  With that many people, however,  you might want to set up a public bulletin
  board where  the archives  of,  say,  the  last month  of the  more popular
  mailing lists are kept.    There are some people in the  network with tools
  that will automatically load incoming mail  such as that,  so the busy-work
  is kept to a minimum.

  * Perhaps the lists  ought to do what we do  with our accounts registration
  each year.  On May 1,  all subscriptions expire automagically.  It is up to
  staff and continuing students to re-register on or before that date.  Could
  not the lists do something similar?

  * The  idea of requiring periodic  re-registration to mailing  lists sounds
  like a  good one  to me,  because  of staff turnover  as well  as departing
  undergraduate/graduate students.   Particularly, if the renewal can be made
  easy.   Of course,  we must remember  that we're relying on volunteer labor
  for all such improvements!

  * I  did not install Mailer  at our site but  whenever I have sent  mail to
  DEADACCT@SOMENODE it gets sent back to me by their mailer stating the local
  user no longer exists.  Perhaps I am wrong or give LISTSERV too much credit
  but I assumed  that the list owner  would get back this  'bounced' mail and
  could take the appropriate action. I do know that the mail looping problems
  have  been solved  when this  *used* to  happen.  I/we  will be  installing
  listserv this week here so I will know better after the install.

  Now I do know that not everyone runs mailer.  I think that this would be an
  incentive  to use  mailer  in  this fashion  so  that  the originator  gets
  notified  of dead  accounts.   This makes  the  whole notification  process
  transparent to  the user since  I much prefer to  tell the user  that their
  correspondent no longer  has an account rather than just  purging the file.
  Doesn't that seem fair?

  I  also believe  it is  better  to cure  the  disease than  just treat  the
  symptoms.  The symptom here is the supposed network load but the real cause
  is the inability of a correspondent  to be notified of non-existent userids
  so the mail just keeps on coming...This  may be idealistic but we certainly
  won't ever get there if we don't try.   We try by using mailer since,  as I
  stated earlier, you at least get that notification. With IBM note you don't
  get anything if  you happen to be  logged off when the  'SPOOLED TO SYSTEM'
  message finally gets sent to you.  If  I am wrong about LISTSERV's reaction
  to such dead mail please tell me so that I can modify our LISTSERV code (if
  that's possible) to send me the returned mail. I can then cure that problem
  by editing that userid out of the list.

  * We joined BITNET in 1983, and have not restricted access at all.   Anyone
  who gets a mainframe account (everyone with valid ID card is eligible)  may
1

                                                                       Page 8


  use BITNET as well as any other utility.  We have not had very much trouble
  with students.    Now and then  somebody thinks it's  neat to send  a chain
  letter, and I get to tear a strip off his (all been male so far - no sexist
  intentions with this pronoun) hide.

  This summer, we have had only 1 (so far)  instance of someone maintaining a
  LISTSERV-type mailing  list ask us  to check on  a person  to see if  he is
  still around and if  not,  to remove his name from  the mailing list.   Our
  systems person can do that.

  I was thinking we enforcers should have our own group,  called BITCOPS,  or
  something appropriate,  so we can share  methods of punishment,  etc.   for
  miscreants.  Anyone interested?

  * We,  too,  allow  unrestricted access -- anyone with a  valid ID card can
  apply for an account, all accounts can use BITNET.   We're a relatively new
  site, though,  and this past semester was really our first with wide-spread
  access.

  We've had a number of problems of the  type "hey this is really neat,  what
  does *this* command do?",  and a number  of students think it's fun to send
  "hi, you don't know me,  but ..." messages to other schools,  especially if
  the userids are remotely feminine.   We squelch  these as we go,  but we're
  still trying  to come up  with a uniform  approach.   (I rather  like Sally
  Webster's solution,  "tear  a strip off his  ...  hide" -- maybe  we should
  adopt that!)

  * The UG-L@BITNIC list (Usage Guidelines)  has a purpose similar to that of
  the suggested  BITCOPS list.    The following is  from the  LISTSERV GROUPS
  file:

  List: UG-L@BITNIC

  Coordinator:   BITNET  Network  Information   Center  (INFO@BITNIC)   USAGE
  GUIDELINES:   Discussion  of the  use  and  abuse  of the  network;   usage
  guidelines and etiquette; local access policies; enforcement of guidelines.

  * Other lists  that are similar to  that of BITCOPS is  NETMON-L discussing
  the NETMON program in  order to catch our malicious little  users and MON-L
  to discuss ways of monitoring the network.   I personally believe that MON-
  L, TRAFIC-L,  and NETMON-L should be collapsed into one list - maybe MON-L.
  Too many lists -  too little disemination of information -  and too much to
  remember.

                       //            ///////     /////
  [[[[[[[[[[         //          ////       /////                 [[[[[[[[[[[
           /[/[[/////////     ///                     /////  [[[[[
         ////   [[[[     /////   [[[[[[    [[[[[[     [[[[/[/[/
  ///////           [[[[[[[[[[[[[      [[[[      [[[[[         //////////////
1

                                                                       Page 9


   *************************************************************************
  * Spotlight Server:  VMNMAES@WEIZMANN                                     *
  ***************************************************************************

  This name server automatically knows of any userid on Weizmann's VM system.
  Users can talk to this server in many different ways:

  1) Interactive messages:

  TELL VMNAMES at WEIZMANN command
  SEND VMNAMES@WEIZMANN command

  Responses sent back from VMNAMES will be via interactive messages.

  2) Files (valid only for Bitnet users):

  VMNAMES will also respond to a file that arrives in either CMS PUNCH format
  (with  or without  a header  - both  are accepted)   or via  the CMS  PRINT
  command.   The file should contain only one  line and it should contain the
  command that you wish to execute.

  VMNAMES will send its  responses back as a file based  upon the information
  contained in the  BITNET NAMES database for  file format and file  class as
  specified by your node.

  3) Mail (valid for all Internet users):

  VMNAMES will accept standard Bitnet mail files as commands.   The mail must
  arrive with a  filetype of 'MAIL' and  a class='M' in order  for VMNAMES to
  recognize the file as  being mail.   This is the format  of Bitnet standard
  mail  files.   The  first  non-blank line  after the  mail  header will  be
  accepted as the VMNAMES command.

  Address your mail to:
  VMNAMES%WEIZMANN.BITNET@WISCVM.ARPA
  if you are located on another network other than Bitnet.

  4) IBM NOTE (valid for Bitnet users):

  VMNAMES will  accept standard  IBM NOTE  format files.    It will  send its
  results back to you  as a file based upon the  information contained in the
  BITNET NAMES database for  file format and file class as  specified by your
  node.

  Commands:

  HELP - returns this  file and will only be returned as either  a file or as
  mail.  HELP will not respond via interactive messages.

1

                                                                      Page 10


  WHOIS - will determine what the person's real name is behind the userid, or
  if lastname is given,  will return the  userid as associated with that last
  name.   Searching by  userid will return one person,   whereas searching by
  lastname may return many people (i.e. WHOIS COHEN) If a match is not found,
  a phonetic search will be performed to try to find a match.

  BITRPT - will allow you to create  customized reports based upon the BITNET
  NAMES  database  of  information.    If  the  request  arrives  via  Bitnet
  interactive message, the response will be via a file.

  Full Syntax:

  BITRPT SELECT  ]
         DISPLAY      
         SORT    
         (   

  where fieldnames can be any of the following:

  Fieldname  Leng   Fieldname description
  ---------- ----   ----------------------------------------------------
  nick         8    Nodename as known to other nodes
  alias        8    Possible alias for this node
  nodenum      4    The sequence number that this node has been assigned
  aliasnum     4    The sequence number for the alias
  via          8    The node that links it in the direction of 'root'
  site        60    The full name of this site
  abbr        30    An abbreviation for this site
  system      25    The operating system currently being run
  machine     25    The current hardware being run for this node
  netsoft     10    The networking software being used (i.e. RSCS)
  msgs         3    Does this node accept messages?
  cmds        10    Does this node accept commands?
  files        4    Does this node accept files?
  country      8    The country this node is found in
  longitude    7    The longitude of the node
  latitude     7    The latitude of the node
  connect      5    Day this node became a BITNET member (julian format)
  mailer      17    The name of it's mailer server machine
  postmast    60    The person to contact relating to electronic mail
  gates       15    The network gateways available at this node
  mformat      9    Preferred mail format protocol
  mclass       1    Preferred mail class
  fformat      9    Preferred file format protocol
  fclass       1    Preferred file class
  tformat      9    Preferred text format protocol
  tclass       1    Preferred text class
  bitdirector 60    The name of the BITNET director for this site
  director    60    The name of the director at this node
1

                                                                      Page 11


  contact     60    The name of the systems programmer to contact
  inform1     60    The name of the person to be informed of 'inform1'
  info1       60    A list of things to inform 'info1' of
  inform2     60    The name of the person to be informed of 'inform2'
  info2       60    A list of things to inform 'info2' of
  linkfail    60    Person to contact in the event of a link failure
  addr       240    (4x60) 4 lines of site's address
  lastup       5    The last day (julian format) this entry updated
  linkspeed    8    The speed of this link
  linktype    12    The type of link this is

  Examples:

  1) BITRPT SELECT ALL DISPLAY nick abbr system SORT nick (NOSEQ would select
  all nodes in the NAMES file to display,  and would display in column format
  the fields  'nick' followed  by 'abbr' followed  by 'system'.    The entire
  report would be sorted alphabetically by 'nick' and no automatic sequencing
  would occur in columns 1-4.  The default is to put in sequencing in columns
  1-4.

  2)  BITRPT SELECT country=usa DISPLAY nick  abbr machine SORT connect would
  select only  those nodes that  are located in  the United States  and would
  display the field 'nick' followed by 'abbr' followed by 'machine' in column
  format.   The entire  report would be sorted by  'connect' in chronological
  order.

  3)  BITRPT SELECT msgs=no cmds=no DISPLAY  abbr SORT connect (REVERSE would
  select any nodes  that have their message  setting to NO and  their command
  setting to NO.  It would display only the 'abbr' field but the report would
  be sorted in reverse chronological order.   Default sequencing would appear
  in columns 1-4.

  Usage notes:

  1) The default is to print the report with sequence numbers in columns 1-4.

  2)  When  SORT is  invoked against a  date field  (connect or  lastup)  the
  default is  to sort it  in chronological order.   If  you wish to  have the
  report sorted in  reverse chronological order,  then specify  the option of
  REVERSE.

  3)  A  report cannot  have more  than 80  columns of  output.   Each  field
  specified  above has  a  certain length  to  which one  space  is added  to
  seperate fields.  If the report you request will be greater than 80 columns
  you will receive  an error message.   If  you wish to create  a wide report
  (132 columns)  then specify the WIDE option.   The WIDE option is not valid
  via Bitnet mail.

1

                                                                      Page 12


  4)  A maximum of two fields can  be selected (NAMEFIND will use Boolean AND
  logic to find a  match)  and a maximum of 6 fields can  be displayed in any
  one report.

  5) All date fields are expressed in Julian format.

  6)  The :country  field has values as obtained from  the International Post
  Office Code list (i.e. Israel is IL and Germany is D).

  7)  Case is  unimportant.   Mixed case was  used above in the  examples for
  clarity reasons only.

  8)  The  fields as stated  above are  positional and required.    The three
  required positional field are: SELECT, DISPLAY, SORT.


   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Received: by YALEVM (Mailer X1.23b) id 1755; Mon, 01 Jun 87 11:09:42 EST
  Date:         Mon, 01 Jun 87 11:05:22 EST
  From:         "Christopher M. Condon" 
  Subject:      Letters to NetMonth
  To:           "Christopher M. Condon" 

  Hi Chris!   I  see you didn't get  any letters this month...   too bad.   I
  thought I'd drop you a line a gloat a bit.   While I'm at it, I'll tell the
  readers that they can send their comments and suggestions to BITLIB@YALEVM.
  All they  have to do to  make sure that  their letter gets published  is to
  note somewhere in  the letter that it  is for the NetMonth  Letters Column.
  Hopefully, you won't have to pull a stunt like this again.

                                    Chris


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  * Subscribing to NetMonth and BITNET SERVERS:

  VM users can be added to the mailing list by issuing the following command:

      TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name

  VAX/VMS users can subscribe in a similar way:

      SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name
1

                                                                      Page 13


  If you cannot send messages in this way, you can send the following command
  as the first line of a mail file to LISTSERV@MARIST:

      SUBSCRIBE NETMONTH Your_full_name

  Arpanet users may use this method, but must address the mail to:

      LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU

  A subscriber  can delete  him/herself  from  the mailing  list  by  sending
  LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

  * Letters to the Editor:  If you have questions  or  comments  about BITNET
  or  NetMonth  that  you  would  like  printed  here,  mail  your l etter to
  BITLIB@YALEVM.  Make  sure that you  specify  in  the "Subject:"  header or
  somewhere in the letter that it is for the  NetMonth  letters  column. This
  doesn't mean that your letter will be printed, but it helps.

  * Article Submissions: The only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVM.

  * Printing this file:  VM users can print this file by  first copying it to
  NETMONTH LISTING and  then printing  the new file.  This will  allow  page-
  breaks and other formatting to be understood by your printer.

  ---------------------------------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."